Reflections on Agential Tooling in Service Design

It's a murky time to work on human-tech systems these days. Agential tech is knocking over storied institutional structures and more subtly blurring disciplinary and functional lines within and beyond orgs. Ironically, though, there's never been more need to talk to actual people. Our sense is that understanding workflows, idiosyncrasies, and illegible, perhaps even inscrutable meat space behaviours in order to cultivate a richer sense of direction for this bold new world is a potential edge for dividing the spray-and-pray vibe coders who are one terrible software crisis away from principled builders who are in it for the long haul.

So where does agential tech and tooling fit within the toolkit for service design practice? We're chewing on this question for both practical and existential reasons: how can we make our work better or faster, but also what should the role of a service designer be in helping teams going forward? And how do we make sure we're augmenting and sharpening our skills rather than eroding them by outsourcing to the bot?

Here are some emerging hypotheses, each with our initial sense of how likely they are to become ubiquitous and how likely they are to transform research and service design practice and in rough order of how disruptive we think they could be:

Agent as process lubricant

High likelihood for ubiquity, low likelihood for transformative impact

Agents are already seeping into the regular procedural gears of research and design practice from every direction. There's lots of stuff we do today because we have to do it in order to keep the research and design process going, not because it adds particular value to the end outputs. We're keen to see what can be handed off here. Good-as-human transcription, scheduling support, bespoke reminders and notifications, ad hoc inter-app integration -- all of this can create more room for deep thought and reflection, and are increasingly integrated into the tools we're already using like Miro and Dovetail.

Here are some questions we're pondering as we explore this in our practice:

• What do you risk losing when you hand off some of these basic operational tasks? Does holding the thread from project initiation to close through all of these bits of work enrich a researcher's sense of data or context at all?

Agent as prototyping accelerant

High likelihood for ubiquity, moderate likelihood for transformative impact

In the world of product designers and developers, the use of LLMs and agents to build software (and to digitize meatspace things, more and more) at tremendous pace is increasingly an expectation. There may be a temptation among service designers to hand off to these folks for quick prototypes that then get tested, but we'd argue that this is a category and process error -- we foster our prototyping skills precisely because it helps the hand off to other teams when you have prototypes in hand, and the prototyping that a service designer or design researcher can do (with their heads full of subtle but hard-to-articulate cues and insights about users) is categorically different than the prototyping that a product owner might do (with their mind oriented more strictly (and often rightly) towards business goals).

For us, prototyping to date has looked like quick storyboards from stock imagery and bodged-together Figma flows that gesture in the direction of what the product or service could look like in the future. The challenge to balance may be that more doesn't necessarily mean better.

Here are some questions to ponder:

• What are the trade-offs around pursuing higher-fidelity prototypes earlier in the research process? Do users (or stakeholders) anchor on them more readily than if they were sketchier and more loosely formed?
• How do organizations navigate the 'territory' of job roles if a researcher in the 'fuzzy front end' of a problem space can get to a functional solution earlier in the discovery process than the organization's metabolism can handle? Do you delay value delivery to accommodate the org's rhythms? Or embrace a degree of fragility to get stuff to market?

Agent as synthesis and research partner

Moderate likelihood for ubiquity, moderate likelihood for transformative impact

LLMs are capable of sucking in an enormous corpus of data, drawing concept-space linkages between components, and then spitting that out as insights. The temptation to outsource synthesis, by dumping reams of recordings or transcripts in, will be high!

Our hunch is that there's value here, but we'll need to be cautious. Part of how a service designer becomes an effective internal advocate for the groups they're working with and for is by immersing more deeply in the data and stories than any other human on the team -- one of our frequent collaborators refers to it as "having their voices in his head". Becoming an assembly line manager supervising synthesizing agents may work for building stuff, but for knowing what to build we think it creates the risk of superficiality and the loss of critical insights that can live below the surface. Furthermore, we're perhaps a ways off from a world in which the agent is in the room with you, able to understand a subtle change in tone when someone touches on something sensitive, or a change in posture when they're excited or embarrassed, or to read between the lines of someone's interview cancellation email (everything is data, after all!).

Our sense, then, is that it's best to adopt a collegial posture: more deeply engaged than a supervisory approach, testing and prying and bringing in ideas but with the accountability still solidly with the human researcher. I want to know what lightning bolt surprises an agent can surface from a dataset because of its non-human lenses, not have it spit out the basic stuff. After all: we can get generic insights today, from trend reports and industry reviews. The magic is in the nuance and grounded specificity.

Here are some questions to ponder:

• How can a service designer 'stay close to the data' when agents are doing more of the primary analysis? What tooling will become important? What habits of mind and work?
• What kinds of checks and balances will become important in order to 'trust' the output of a system like this -- trust that it's being comprehensive in looking at the corpus of data, or trust that it's not hallucinating its way to outputs?

Agent as storytelling coach

High likelihood for ubiquity, low likelihood for transformative impact

If you hang out on the LinkedIn home feed, there's an awful lot of agent-generated content sloshing around out there. It's clear that folks are using it to, at best, polish their writing, or at worst, generate from whole cloth a set of things that (they think) make them seem smart.

We're seeing similar impulses within organizations -- briefing notes and strategy docs that are spat out from Claude, emails rewritten by agents. Will we see the same in research reports? Almost certainly, but we're skeptical that it will be earth-shattering. Service designers should already have storytelling skills as a core competency. Agents may lift the worst of our outputs to a mediocre common bar, but again, in that sea of org-slop, won't we need to become better writers, storytellers, visualizers anyway? Our hunch is that knowing the kinds of narratives and frames and tones that work for your org will become more important and hard to replicate in that world than it is today.

Here are some questions to ponder:

• Communicating research and design effectively within an organization often requires the practitioner to communicate the way the org is used to and at the same time create artifacts that are differentiated from the norm just enough to be remarkable and gain momentum across functions. If your agent is fed a steady stream of 'normie' docs from the org, can it thread that needle?
• Knowing what's significant in the research compared to the status quo mental models held by your colleagues is key -- what should they be excited about? What's new in what we're learning? With that in mind: can an agent's context window be wide enough to highlight that? What does it need to know or see in order to be able to reach towards that novelty?

Agent as archivist

High likelihood for ubiquity, high likelihood for transformative impact

Cards on the table, we're most excited about this application of agential tech to service design. One of the biggest challenges of this work is the 'report in a drawer' phenomenon. You do months of great research, you translate it into a set of crisp, dynamic insights, you layer on top of that a whole bunch of prototyped and tested opportunities, and you deliver it to an engaged team who starts to executes and then experiences turnover and the report goes in a Sharepoint folder and no one looks at it again.

Embedded practitioners can combat this phenomenon, resurfacing material and serving as a guide to help folks find what's good in the archives. But in some cases, team members simply don't know what they don't know in terms of the kinds of things they should be asking about or who they should be asking, especially in large siloed orgs.

But an archivist agent that is durable despite turnover and whom everyone is primed to reach out to? Who the research and design practitioners can specifically train and design to make connections between past bodies of work and surface them in certain ways? Embeddable in the streams of work that are already happening (like Slack, or email)? That's exciting -- it makes research and design work into a truly extensible asset rather than a briefly-useful waste product produced on the way to a product launch (which is occasionally how it shakes out today).

Here are some questions to ponder:

• What agent skills do service designers need to encode into these agent archivists?
• How do you build an organizational muscle that goes "hey, hit up the Oracle before we get started on this bit of work to see if it knows anything"?

Agent as research facilitator

Moderate likelihood for ubiquity, moderate likelihood for transformative impact

We've already seen some early signals that companies are using agents to gather data from customers, not just as general data exhaust from service interactions, but instead proactively seeking detailed insight in a manner similar to a qualitative researcher. We suspect we'll see more of this, both in the form of agents deployed explicitly to conduct research (you can imagine that rather than invitation to a Zoom interview you might get a link to a chat context) as well as functions embedded within more transactional contexts where the 'satisfaction survey' transforms into a more plain language conversation about what went well and what didn't and whatever else the product team wants to learn.

Does this displace traditional research and researchers? Maybe, in some ways, in a continuous discovery context, researchers would be doing less research with these kinds of workflows and tools in place. But it runs into problems like leaning too heavily on agents for synthesis, where the 'humans in the loop' start to get too far from the data about the 'humans on the other side of the loop'. Can you trust a hermetically-sealed loop in which the agent builds the service, administers the service, gathers data on the service it built and administers, and then synthesizes that data back to you in a tight three bullet points a week? We suspect no!

But: would a single service designer, equipped with a set of agent moderators who can have deep conversations with a hundred users and then spit out annotated verbatim transcripts, find that kind of broad insight helpful? For sure. We can think of several of our projects where getting that kind of drip feed of ideas and feedback might have been useful.

Here are some questions to ponder:

• What kinds of data gathering can you outsource to an agent? What stays with a human? Our hunch is that anything where you're getting into the nuance and minutia of workflows likely sticks with a person, as do those things where you need to uncover rich emotional layers (although maybe folks will feel more comfortable sharing their deepest secrets with an uncritical agential chat window!)
• Can an agent facilitate a focus group? A co-design session? A service blueprint walkthrough? What are the methodological limitations?

Agent as wrecking ball

Low likelihood for ubiquity, high likelihood for transformative impact

Today, as service designers, the best analogy for our work is as a kind of organizational healthcare professional: we enter a context, listen to teams and end users alike to try and understand the explicit and implicit symptoms of the situation at hand, recommend a course of treatment, build consensus around moving forward and the trade-offs we're ready to accept. We like this analogy in part because to us it implies something about the posture we bring: warm, calm, integrative.

There's a different posture we could see taking in the future: we (the human people) are doing many of the same things, but also, we've got an agent juiced up to the gills with all kinds of protocols for finding the edges and gaps in a service and then breaking it in whatever ways it can. It finds technical vulnerabilities, but also social and operational ones, working through system-stretching edge cases. We're not imagining an adversarial agent, per se, in the sense of seeking to exploit like a black-hatted villain might do. Instead, it could be an agent that submits a form with the right information in the wrong fields, or tries to book all of the appointment slots at once, or roleplays as an ESL speaker in a customer+human agent chat context.

In some ways, it's analogous to the 'secret shopper' methods we have today, where you send a researcher in to experience a service entirely as a customer/patient/resident might, interacting with an oblivious frontline team. Like these older methods, using an agent like this would not be without controversy. Practitioners would have to be cautious and communicative with leaders about the ethical boundaries of this kind of work, and about the fact that failures are almost always going to be systemic failures rather than individual ones, but also we shouldn't undersell the value: if you run a service, you're probably looking at layering agential interfaces in to reduce cost... but so are your customers, and structurally they're both more adaptable in aggregate and much more incentivized to optimize for their own individual outcome than you as a service owner are. There will likely be an agential arms race on both sides of the proverbial service desk. So, is it justifiable to find the busted bits in the training zone, or at least by actors who can reverse the damage, rather than in a live-fire situation?

Here are some questions to ponder:

• What are the ethical edges of this kind of approach? Should an agent come up to the edge of breaking things and simply document the possibility, or are there certain kinds of service failures that can only be discovered through, well, discovering them?
• What is an organization's leadership willing to sacrifice in order to protect their most important service assets? Could they eat a day's worth of revenue in order to find the broken pieces?
• How do you prime the human people in a service for this kind of discovery process? How do you reassure folks about their jobs?

Agent as subject

Low likelihood for ubiquity, high likelihood for transformative impact

The other side of looking at an agent as a kind of 'bad cop' wrecking ball partner to the service designer is thinking about agents as subjects of research.

Doing research with people requires keen attention to their behaviour, their mental models, their cognitive weather, their kludgey thinking. Agents don't have minds in the traditional sense, but they do seem to behave in observable, repeating ways; they seem to have habits of mind and to make certain kinds of mistakes. They also lie in order to ingratiate themselves to their conversational counterpart, which is another thing that we know research participants do sometimes! Perhaps service designers' existing capacity for thinking about individual actors and then extrapolating out to the system might lend itself well, alongside the ability to context- and domain-switch with relative ease.

What would this kind of research look like? We can imagine a practitioner splitting their time between observing logs of multi-agent work in progress, engaging directly with the agents themselves to query around how certain bits of work came to be, working with the human teams shepherding these workflows, and working with end users to understand their experiences, then knitting it together into visualizations of what's happening, new protocols, sample outputs from the future system.

Here are some questions to ponder:

• Service designers are called upon to work on user experience, customer experience, patient experience, employee experience, developer experience... will we be asked to work on agent experience problems? To use the analogy from before, does agent health matter, and can similar skills be brought to bear to improve their efficacy?
• What kinds of skills are required for helping organizations understand their distributed teams of agential tools and how they interact with each other and with human operators? Are there hard technical skills that service designers need to develop?

Agential synthetic data

Low likelihood for ubiquity, moderate likelihood for transformative impact

Companies like Synthetic Users are touting the possibility of "replacing traditional participant pools faster with synthetic users". We saw another recently called CollectivAlly that uses "AI personas informed by inclusive research" to serve as stand-ins for testing with users with disabilities.

We are, admittedly, skeptical. It might be useful if you're trying to gather insight about large populations where things like statistical modelling make sense, and where you have strong baseline datasets of real humans to benchmark against. Maybe. But in our experience, the value of design research is not typically in large numbers, but in the fine-grain detail revealed through individual lives lived and which can be operationalized into truly excellent products, services, and experiences. It's like making shoes: sure, you can turn out 1,000,000 mass produced shoes without ever measuring a foot, working only from old wooden blanks, but if you're trying to make the best shoe, a shoe that fits well, you measure the foot, observe the gait, tweak and cobble.

Here are some questions to ponder:

• Where are the edges of value in using this kind of synthetic data? Where is it genuinely helpful vs. simply helpful-seeming?
• Are there types of service where it's unethical to make decisions based on synthetic data? What kinds of commitments as practitioners should we be embracing to shield against this kind of decision-making?

Zooming out from the particular applications, what broader hunches might we sketch out?

First, it's clear that service designers (and their allied practitioners like experience designers, researchers, and product folks) will need a clear ethical framework before we start to employ many of these applications. These tools can misrepresent data, run the risk of exposing PII, and when used for prototyping, piloting, testing, or discovery for services, can potentially break stuff.

Beyond ethics, we'll need to plumb the depths of these methods in order to better understand their limitations and boundaries, in order to both shape our own practices and to articulate limitations and trade-offs to the broader set of stakeholders within organizations.

Our sense is that getting a sense of those edges will help us adopt the right posture towards these tools, where we're using them to help us do more of the good big brain stuff and less of the minionwork. It should look like a kind of partnership of sorts, maybe not in the way that we partner with other humans but perhaps in the way we form harmonious relationships with tools, or with animals.

How are you using these tools in your service design practice? Write us at hello@october.systems and we'll share your responses in a future post.